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ABSTRACT 

This paper describes the 01 Exchange Format, a standard for exchanging cal- 
ibrated data from optical (visible/infrared) stellar interferometers. The standard 
is based on the Flexible Image Transport System (FITS), and supports storage 
of the optical interferometric observables including squared visibility and closure 
phase - data products not included in radio interferometry standards such as 
UV-FITS. The format has already gained the support of most currently-operating 
optical interferometer projects, including COAST, NPOI, IOTA, CHARA, VLTI, 
PTI, and the Keck Interferometer, and is endorsed by the IAU Working Group 
on Optical Interferometry. Software is available for reading, writing and merging 
01 Exchange Format files. 

Subject headings: methods: data analysis - techniques: interferometric - 
instrumentation: interferometers - techniques: image processing 
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1. Introduction 

The idea of a common data format for visible-wavelength and infrared astronomical 
interferometry (hence referred to collectively as "optical interferometry" ) arose through 
discussions at the June 2000 NSF-sponsored meeting in Socorro (McAlister & Cornwell 
2000). Since 2001, T.P. and J.S.Y. have been responsible, under the auspices of the 
International Astronomical Union (IAU), for coordinating discussion on this topic, and for 
producing and maintaining the specification document for a format based on the Flexible 
Image Transport System (FITS) (Hanisch et al. 2001). 

1.1. Motivation 

The motivation for a creating a data format specific to optical interferometry was two- 
fold. Firstly, existing formats designed for radio interferometry such as UV-FITS (Cotton 
et al. 1990) and FITS-IDI (Flatters 2000) do not describe optical data adequately. Secondly, 
the more popular UV-FITS format is poorly defined - its content has evolved and the 
format is partly defined by reference to the behaviour of the AIPS software - and based on 
the deprecated FITS "Random Group" conventions. 

The principal shortcoming of the radio interferometry formats is that Fourier data is 
stored as complex visibilities. The noise models for radio and optical interferometry are 
quite different; optical interferometers must usually integrate incoherently to obtain useful 
signal-to-noise. Thus the "good" observables in the optical are calibrated fringe power 
spectra (squared visibility amplitudes) and bispectra (triple product amplitudes and closure 
phases), rather than complex visibilities. A file format based on complex visibilities can 
only encode (optical) closure phases if corresponding visibility amplitude and closure phase 
measurements are made simultaneously, and even then the uncertainties on the closure 
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phases are not stored (radio interferometry analysis software assumes zero closure phase 
error). There is also no way of saving bispectrum (triple product) amplitudes. 

1.2. History 

Preliminary drafts of the specification for an optical interferometry format were 
discussed by the community at the 198th Meeting of the American Astronomical Society 
in June 2001, and the August 2001 Meeting of the IAU Working Group on Optical/IR 
Interferometry. The discussion continued by email amongst various interested parties, and 
the document was revised. 

A public pre-release of the Format Specification and accompanying example C code 
was made in March 2002, followed by a second pre-release of the document in April 2002. 
This draft was discussed at the August 2002 IAU Working Group Meeting. Comments were 
presented by participants from the European Southern Observatory and the Interferometry 
Science Center (now the Michelson Science Center). Since the IAU Working Group 
meeting there were two further pre-releases of the Format Specification, prior to the first 
"production" release. 

The standard was frozen on 7 April 2003 (release 5 of the Format Specification), 
meaning that subsequent changes would require increments of the revision numbers for the 
changed tables. The history of the Format Specification is summarized in Table 1. 

The standard is now supported by the majority of optical interferometer projects, 
including COAST, NPOI, IOTA, CHARA, VLTI, PTI, and the Keck Interferometer. 



EDITOR: PLACE TABLE 1 HERE. 
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1.3. OIFITS Publications 

This paper contains the formal definition of the standard, in Sec. 3 onwards. As earlier 
versions of the Format Specification have only been distributed via the world- wide- web, this 
paper formalises the standard and serves as a published reference for it. Further discussion 
explaining the design decisions and providing explicit pointers to existing software for 
reading and writing the format can be found in Pauls et al. (2004), which is intended as a 
"companion" to the official Format Specification given here. 

A first application of the Exchange Format, a "beauty contest" to compare the 
performance of a number of image reconstruction software packages, is described by Lawson 
et al. (2004). The contest demonstrated that four different international groups could 
faithfully reconstruct images from simulated datasets in the OIFITS format. 

No alterations have been made to the standard since release 5 of the Format 
Specification. The text in Sec. 3 onwards is substantially the same as that in release 5, 
apart from minor changes to clarify certain points and to conform to the journal style. The 
revision numbers of all tables defined by the standard remain at unity. 

2. Purpose and Scope 

By defining and maintaining a common data format, we hope to encourage the 
development of common software for analysis of data from optical stellar interferometers, 
and to facilitate the exchange of data between different research groups. In this way, the 
limited Fourier coverage of current instruments can be ameliorated by combining data from 
several interferometers. An example of this is given in the paper by Monnier et al. (2004). 

The format is intended to support the storage of calibrated, time-averaged data. Such 
data can be prepared from the raw fringe measurements without using information about 
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the detailed structure of the target (i.e. without doing any astrophysical interpretation), 
yet once the data is in the format, it can be analysed without knowing the details of the 
instrument. Calibrated data from different interferometers can be treated in the same way 
(provided there are no residual systematic errors). 

The standard includes the information needed to perform "imaging" from a calibrated 
data-set. Here imaging refers loosely to any process for making inferences about the sky 
brightness distribution from the data. The standard explicitly allows extra binary tables or 
columns, beyond those it defines, to be used to store additional information. In this way, 
the standard can be used for other purposes besides imaging, e.g. for astrometry or as an 
archive format. 

We suggest that the common data format be referred to as the "01 Exchange Format" , 
or the "Exchange Format" when the context is clear. A suitable very short moniker is 
"OIFITS" (or "OI-FITS"). 

3. Document Conventions 

In what follows we use the FITS binary table nomenclature of keywords and column 
headings. The values associated with the keywords can be considered as scalars, while each 
column can be simply an array, or an array of "pointers" to other arrays. The following 
data types are used in the standard: I = integer (16-bit), A = character, E = real (32-bit), 
D = double (64-bit), L = logical. In the tables below, the number in parentheses is the 
dimensionality of the entry. The table names given below correspond to the values of the 
EXTNAME keyword. Other mandatory keywords describing the structure of the FITS 
binary tables (see Hanisch et al. 2001) have been omitted from this document. Hanisch 
et al. (2001) also describes various extensions to binary tables that are not part of the FITS 
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standard. None of these are currently used in this format. The definitions of all tables have 
been "frozen" since April 2003. All revision numbers are currently equal to one. Any future 
changes will require increments in the revision numbers of the altered tables. 



The conventions described here are generally identical to those used in radio 
interferometry and described in standard textbooks (e.g. Thompson et al. 1986). 

4.1. Baseline vector 

The baseline vector between two interferometric stations A and B whose position 



u is the East component and v is the North component of the projection of the baseline 
vector onto the plane normal to the direction of the phase center, which is assumed to be 
the pointing center. 

4.3. Complex Visibility 

The basic observable of an interferometer is the complex visibility, which is related to 
the sky brightness distribution I(x, y) by a Fourier Transform: 



4. Definitions and Assumptions 



vectors are x\ and x~b is defined as AB — x~b — x~a- 



4.2. 



UV coordinates 




(1) 
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x and y are displacements (in radians) in the plane of the sky (which is assumed to be 
flat). The origin of this coordinate system is the phase center, x is in the direction of 
increasing right ascension (i.e. the x axis points East), and y is in the direction of increasing 
declination (the y axis points North). With x and y defined, the above equation defines 
the sign convention for complex visibilities that should be used in the data format. The 
visibility is normalized by the total flux from the target, which is assumed to remain 
constant over the time spanned by the measurements in the file. Neither the field of view 
over which the "total" flux is collected, or the field of view over which fringes are detected 
(i.e. the limits of the above integral), can be inferred from the data file. 

4.4. Squared Visibility 

The squared visibility is simply the modulus squared of the complex visibility: 

S(u,v) = \V(u,v)\ 2 . (2) 

4.5. Triple Product 

The triple product, strictly the bispectrum, is the product of the complex visibilities 
on the baselines forming a closed loop joining three stations A, B and C. In the following 
expression, (ui,Vi) is the projection of AB and (1/2,^2) is the projection of BC (and hence 
{ui + u 2 , Vi + v 2 ) is the projection of AC): 

T(ui, vi, u 2 , v 2 ) = V(ui, vi) V(u 2 , v 2 ) V*(ui + u 2 , v x + v 2 ) . (3) 



- 9- 



4.6. Noise model for triple product 

The data are assumed to be complex triple products averaged over a large number 
of "exposures". In such a case, the noise can be fully described in terms of a Gaussian 
noise ellipse in the complex plane. Photon, detector and background noise tend to lead to 
noise ellipses that are close to circular. On the other hand, fluctuating atmospheric phase 
errors across telescope apertures typically cause fluctuations in the amplitude of the triple 
product which are much larger than the fluctuations in the phase. Thus the "atmospheric" 
contribution to the noise ellipse is elongated along the direction of the mean triple product 
vector in the Argand diagram, as shown in Fig. 1. Such noise needs to be characterised in 
terms of the variance a\ perpendicular to the mean triple product vector and the variance 
crjj parallel to T. We can parameterize the perpendicular variance in terms of a "phase 
error" a e = (lS0/n)(a±/\T\). The phase error gives an approximate value for the rms error 
in the closure phase in degrees. We denote cry as the "amplitude error" . 

EDITOR: PLACE FIGURE 1 HERE. 

In many cases, the observer may be interested primarily in the closure phase and not 
the triple product amplitude, and therefore may choose not to calibrate the amplitude. 
Such a case can be indicated in the above notation as an infinite amplitude error and a 
finite phase error. The data format specifies that such a case should be indicated by a 
NULL value for the amplitude (the amplitude error value is then ignored). 

4.7. Noise model for complex visibility 

There was much discussion on the (now defunct) oi-data@rsd.nrl .navy .mil email 
list of the representation to use for complex visibilities in the standard. A number of 
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different classes of data can be represented as complex visibilities, including several varieties 
of differential phase data. In all cases the standard should only be used to store averaged 
data. Thus, as with triple products, we must consider the shape of the noise ellipse in the 
complex plane. 

It has been demonstrated (Hummel et al. 2002) that both circularly-symmetric noise, 
and noise ellipses elongated parallel to or perpendicular to the mean vector can occur in 
practice. Thus far there has been no evidence for noise ellipses elongated parallel to the 
real or imaginary axes, although examples of some classes of data have yet to be presented. 
Hence an amplitude/phase representation of complex visibilities, mirroring that used for 
triple products, has been adopted in the current version of the standard. 

5. FITS File Structure 

A valid exchange-format FITS file must contain one (and only one) OLTARGET 
table, plus one or more of the data tables: OLVIS, OLVIS2, or OLT3. Each data table 
must refer to an OLWAVELENGTH table that is present in the file. There may be more 
than one of each type of data table (e.g. OLVIS2). One or more OLARRAY tables (or 
equivalent e.g. for aperture masking, in future releases of the standard) may optionally be 
present. Where multiple tables of the same EXTNAME are present, each should have a 
unique value of EXTVER (this according to the FITS standard - however the example C 
code and J.D.M.'s IDL software do not require EXTVER to be present). 

The tables can appear in any order. Other header-data units may appear in the file, 
provided their EXTNAMEs do not begin with "OI_" . Reading software should not assume 
that either the keywords or the columns in a table appear in a particular order. This is 
straightforward to implement using software libraries such as cfitsio. 
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Any of the tables may have extra keywords or columns beyond those defined in the 
standard. It would facilitate the addition of new keywords and columns in future releases 
of the standard if the non-standard keywords and column names were given a particular 
prefix e.g. "NS_" , to avoid conflicts. 

6. Tables Defined by the Standard 

6.1. OI_ARRAY (revision 1) 

As defined, this table is aimed at ground-based interferometry with separated 
telescopes. Alternative tables could be used for other cases. These must have at least an 
ARRNAME keyword, for cross-referencing purposes. Each OI_ARRAY-equivalent table in 
a file must have a unique value for ARRNAME. 

Keywords 

OLREVN I Revision number of the table definition 

ARRNAME A Array name, for cross-referencing 

FRAME A Coordinate frame 
ARRAYX 

ARRAYY D Array center coordinates (meters) 
ARRAYZ 
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Column Headings (one row for each telescope) 



TEL_NAME 



DIAMETER 



STAXYZ 



STA_NAME 



STAJNDEX 



A (16) 
A (16) 

1(1) 

E(l) 

D(3) 



Telescope name 



Element diameter (meters) 

Station coordinates relative to array center (meters) 



Station name 



Station number 



Number of elements 



There is no keyword giving the number of elements (NELEMENT in a previous revision 
of this document), as this is equal to the number of rows in the FITS binary table, which is 
given by the standard NAXIS2 keyword. For the same reason, there are no format- specific 
keywords giving the number of rows in any of the other tables. 



If the FRAME keyword has the value "GEOCENTRIC" , then the coordinates are given 
in an earth-centered, earth-fixed, Cartesian reference frame. The origin of the coordinates is 
the earth's centre of mass. The z axis is parallel to the direction of the conventional origin 
for polar motion. The x axis is parallel to the direction of the intersection of the Greenwich 
meridian with the mean astronomical equator. The y axis completes the right- handed, 
orthogonal coordinate system. 

Currently, no other values for the FRAME keyword may be used. This will change if 
the need arises. 



Coordinate frame 
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Array coordinates 

The ARRAYX, ARRAYY, and ARRAYZ keywords shall give the coordinates of the 
array center in the coordinate frame specified by the FRAME keyword. Element coordinates 
in the main part of the table are given relative to the array center, in the same coordinate 
frame. Coordinates are given in meters. 

Station number 

Each row in the table shall be assigned a unique station number, which shall be used 
in other tables as an index into this one. The table structure is the simplest possible i.e. 
there is no explicit concept of different "configurations" within the table. Each row in the 
table shall correspond to a distinct set of station coordinates used in taking the data stored 
in the file. 

Element diameter 

This is the effective aperture size, e.g. if the telescope is stopped down. 

6.2. OI_TARGET (revision 1) 

Keywords 

OLREVN I Revision number of the table definition 
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Column Headings (one row for each source) 



TARGET JD 


1(1) 


Index number 


TARGET 


A 


(16) 


Target name 


RAEPO 


D 


(1) 


RA at mean equinox (degrees) 


DECEPO 


D 


(1) 


DEC at mean equinox (degrees) 


EQUINOX 


E 


(!) 


Equinox 


RA_ERR 


D 


(1) 


Error in RA at mean equinox (degrees) 


DEC_ERR 


D 


(!) 


Error in DEC at mean equinox (degrees) 


SYSVEL 


D 


(!) 


Systemic radial velocity (meters per second) 


VELTYP 


A 


(8) 


Reference for radial velocity ("LSR", "GEOCENTR", etc.) 


VELDEF 


A 


(8) 


Definition of radial velocity ("OPTICAL", "RADIO") 


PMRA 


D 


(!) 


Proper motion in RA (degrees per year) 


PMDEC 


D 


(1) 


Proper motion in DEC (degrees per year) 


PMRA_ERR 


D 


(1) 


Error of proper motion in RA (degrees per year) 


PMDEC_ERR 


D 


(1) 


Error of proper motion in DEC (degrees per year) 


PARALLAX 


E 


(1) 


Parallax (degrees) 


PARA_ERR 


E 


(!) 


Error in parallax (degrees) 


SPECTYP 


A 


(16) 


Spectral type 



Target position 

The RAEPO and DECEPO columns shall contain the right ascension and declination 
respectively of the phase center at the standard mean epoch, in degrees. RA_ERR and 
DEC_ERR shall contain the one-sigma uncertainties in these quantities. The phase center 
is assumed to be the pointing center. The EQUINOX field shall contain a (floating point) 
Julian year giving both the epoch of the position (RAEPO, DECEPO) and the equinox 
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for the celestial coordinate system in which the position is expressed. The PMRA and 
PMDEC columns should contain the proper motions of the source in right ascension and 
declination respectively, in degrees per Julian year. If the proper motion is unknown 
then both fields should be set to zero. PMRA_ERR and PMDECLERR shall contain the 
one-sigma uncertainties in these quantities. If an apparent position at the time of an 
observation is required, it should be obtained by applying the appropriate transformations 
to the catalogue position given by RAEPO and DECEPO, making use of PMRA, PMDEC, 
and PARALLAX. 



Velocity Information 

The SYSVEL column shall give the systemic radial velocity of the target (positive if 
receding). The VELTYP column shall contain a string that specifies the frame of reference 
for the systemic velocities. The string shall be one of the following: 

LSR Local Standard of Rest 

HELIOCEN Relative to the SUN 

BARYCENT Solar system barycenter 

GEOCENTR Center of mass of the earth 

TOPOCENT Uncorrected 
The VELDEF column shall contain a string indicating the convention used for 
the (relativistic) systemic velocities. It shall be either "RADIO" or "OPTICAL" (the 
distinction is not important for velocities much less than the speed of light). 
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6.3. OI_WAVELENGTH (revision 1) 

Keywords 

OLREVN I Revision number of the table definition 
INSNAME A Name of detector, for cross-referencing 

Column Headings (one row for each wavelength channel) 

EFF_WAVE E Effective wavelength of channel (meters) 
EFF_BAND E Effective bandpass of channel (meters) 

Name of detector 

Each OLWAVELENGTH table in a file must have a unique value for INSNAME. 

Wavelengths 

Each OLWAVELENGTH table describes the spectral response of detector(s) with a 
number of spectral channels. Each table gives the wavelengths for one or more of the data 
tables (OLVIS, 0LVIS2, 0LT3), and will often correspond to a single physical detector. 

The EFF_WAVE column shall contain the best available estimate of the effective 
wavelength of each spectral channel, and the EFFJ3AND column shall contain the best 
available estimate of the effective half-power bandwidth. These estimates should include 
the effect of the earth's atmosphere, but not the spectrum of the target (the effect of the 
target spectrum should be taken into account as part of any model- fitting/ mapping process, 
i.e. the target spectrum is part of the model). 
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6.4. OI_VIS (revision 1) 

Keywords 

OLREVN I Revision number of the table definition 
DATE-OBS A UTC start date of observations 
ARRNAME A (optional) Identifies corresponding OLARRAY 
INSNAME A Identifies corresponding OLWAVELENGTH table 



Column Headings (one row for each measurement) 



TARGET JD 


1(1) 


Target number as index into OLTARGET table 


TIME 


D(l) 


UTC time of observation (seconds) 


MJD 


D(l) 


Modified Julian Day 


INT_TIME 


D(l) 


Integration time (seconds) 


VISAMP 


D (NWAVE) 


Visibility amplitude 


VISAMPERR 


D (NWAVE) 


Error in visibility amplitude 


VISPHI 


D (NWAVE) 


Visibility phase in degrees 


VISPHIERR 


D (NWAVE) 


Error in visibility phase in degrees 


UCOORD 


D(l) 


U coordinate of the data (meters) 


VCOORD 


D(l) 


V coordinate of the data (meters) 


STAJNDEX 


1(2) 


Station numbers contributing to the data 


FLAG 


L (NWAVE) 


Flag 
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6.5. OI_VIS2 (revision 1) 

Keywords 

OLREVN I Revision number of the table definition 
DATE-OBS A UTC start date of observations 
ARRNAME A (optional) Identifies corresponding OLARRAY 
INSNAME A Identifies corresponding OLWAVELENGTH table 



Column Headings (one row for each measurement) 



TARGET JD 

TIME 

MJD 

INT_TIME 

VIS2DATA 

VIS 2 ERR 

UCOORD 

VCOORD 

STAJNDEX 

FLAG 



I (I) Target number as index into OLTARGET table 

D (1) UTC time of observation (seconds) 

D (1) Modified Julian Day 

D (1) Integration time (seconds) 

D (NWAVE) Squared Visibility 

D (NWAVE) Error in Squared Visibility 

D (1) U coordinate of the data (meters) 

D (1) V coordinate of the data (meters) 

I (2) Station numbers contributing to the data 

L (NWAVE) Flag 
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6.6. OI_T3 (revision 1) 

Keywords 

OLREVN I Revision number of the table definition 
DATE-OBS A UTC start date of observations 
ARRNAME A (optional) Identifies corresponding OI_ARRAY 
INSNAME A Identifies corresponding OLWAVELENGTH table 



Column Headings (one row for each measurement) 



TARGET JD 


1(1) 


Target number as index into OLTARGET table 


TIME 


D(l) 


UTC time of observation (seconds) 


MJD 


D(l) 


Modified Julian Day 


INT_TIME 


D(l) 


Integration time (seconds) 


T3AMP 


D (NWAVE) 


Triple Product Amplitude 


T3AMPERR 


D (NWAVE) 


Error in Triple Product Amplitude 


T3PHI 


D (NWAVE) 


Triple Product Phase in degrees 


T3PHIERR 


D (NWAVE) 


Error in Triple Product Phase in degrees 


U1COORD 


D(l) 


U coordinate of baseline AB of the triangle (meters) 


V1COORD 


D(l) 


V coordinate of baseline AB of the triangle (meters) 


U2COORD 


D(l) 


U coordinate of baseline BC of the triangle (meters) 


V2COORD 


D(l) 


V coordinate of baseline BC of the triangle (meters) 


STAJNDEX 


1(3) 


Station numbers contributing to the data 


FLAG 


L (NWAVE) 


Flag 



The following comments apply to one or more of the OLVIS, OLVIS2, and OLT3 tables. 
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Cross-referencing 

Each data table must refer (via the INSNAME keyword) to a particular 
OLWAVELENGTH table describing the wavelength channels for the measurements. 
Each data table may optionally refer, via the ARRNAME keyword, to an OI_ARRAY table. 

Start date of observations 
This shall be a UTC date in the format YYYY-MM-DD, e.g. "1997-07-28". 

Time of observation 

The value in the TIME column shall be the mean UTC time of the measurement in 
seconds since Oh on DATE-OBS. Note this may take negative values, or values > 86400 
seconds, and hence the epoch of observation for the particular table is not restricted to 
DATE-OBS. 

The value in the MJD column shall be the mean UTC time of the measurement 
expressed as a modified Julian Day. It might be appropriate to use the MJD values 
instead of the TIME values when dealing with long time-spans, but the standard makes no 
stipulation in this regard. 

Integration time 

The exchange format will normally be used for interchange of time-averaged data. The 
"integration time" is therefore the length of time over which the data were averaged to yield 
the given data point. 
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Data arrays 

If the triple product amplitudes are meaningless, as is the case for COAST data, NULL 
values for T3AMP may be used. The closure phases should still be treated as valid. 

NWAVE is the number of distinct spectral channels recorded by the single (possibly 
"virtual") detector, as given by the NAXIS2 keyword of the relevant OLWAVELENGTH 
table. 

Complex visibility and visibility-squared UV coordinates 

UCOORD, VCOORD give the coordinates in meters of the point in the UV plane 
associated with the vector of visibilities. The data points may be averages over some region 
of the UV plane, but the current version of the standard says nothing about the averaging 
process. This may change in future versions of the standard. 

Triple product UV coordinates 

The U1COORD, V1COORD, U2COORD, and V2COORD columns contain the 
coordinates of the bispectrum point - see Sec. 4 for details. Note that U3COORD and 
V3COORD are implicit. 

The corresponding data points may be averages in (bi-) spatial frequency space, but 
this version of the standard does not attempt to describe the averaging process. 
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Flag 

If a value in this vector is true, the corresponding datum should be ignored in all 
analysis. 

6.7. Optional Tables 

It may be useful to allow for some optional tables. For example, there might be one 
that contains instrument specific information, such as the backend configuration. Another 
optional table could contain information relevant to astrometry. The EXTNAMEs of 
additional tables should not begin with "OL" . 

Development of the format was performed under the auspices of the IAU Working 
Group on Optical/IR Interfere metry, and has the strong support of its members. We would 
like to thank Peter R. Lawson (Chair of the Working Group) for his encouragement and 
support. 

The authors would like to thank David Buscher, Christian Hummel, and David 
Mozurkewich for providing material for the Format Specification and the OIFITS website. 
We would like to take this opportunity to thank all those in the community who have 
contributed to the definition of the format and to its take-up by many interferometer 
projects. 
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Fig. 1. — Noise model for triple product. The figure is an Argand diagram showing the 
mean triple product T with its associated noise ellipse, elongated parallel to T. See text for 
explanation. 
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Table 1. History of the 01 Exchange Format. 



Date 



Description 



2002/03/25 Pre-release of document and example code — Release 1 of Format Specification 

2(1(12/04/25 Minor correction to document — Release 2 of Format Specification 

2002/11/26 Post-IAU-WG-meeting release of document and example - Release 3 of Format Specification 

2003/02/17 Release of document, C and IDL code to fix problem in OI-TARGET table - Release 4 of Format Specification 

2003/04/07 Freeze of format specification. Revision numbers of all tables set to unity - Release 5 of Format Specification 

2005 This paper, no changes to Exchange Format or table revision numbers 



